In traditional computer programming systems, computer programs exist as platform-dependent, compiled object code within computer system memory or other computer storage media. Program code in such systems is typically evaluated based upon machine code execution time rather than source code compilation time because the translation or compilation of source code in these systems is static, (usually occurring only once prior to execution) rather than dynamic (occurring prior to each execution). Program code evaluation in such systems may also consider compiled code size either as an indicator of code efficiency and therefore speed or because of limited data processing system storage.
More recently, computer programming systems have begun to implement an interpreted language model in which each line of code is translated to machine executable or “native” code in succession during program execution. Interpreted languages include Basic, LISP, Smalltalk, and JAVA, developed by Sun Microsystems, Inc. Interpreted languages are often platform-independent and are therefore well-suited to distributed or communications network environments such as the Internet or World Wide Web (WWW) in which client or server data processing systems having various platforms may be in communication with one another. In such systems, an interpreter is often utilized locally on each system to receive and translate or interpret each line of platform-independent code to executable native code. Under the JAVA system, a JAVA program is created by first compiling code written in JAVA's well-defined source code format into compact, architecture-neutral object code known as JAVA bytecodes. Bytecodes are then executed at runtime by an interpreter known as a JAVA Virtual Machine (JVM) residing on a client or server computer. A JAVA “virtual” machine is not a physical hardware platform, but rather a low-level software emulator which reads and interprets individual bytecodes so that corresponding instructions may be executed by a native microprocessor. A JVM can be implemented on many different processor architectures and operating systems and JAVA bytecodes are consequently executable on numerous platforms.
The use of interpreted-language computer programming, while often yielding portable, platform-independent code, suffers from several drawbacks. Code interpreters such as the JAVA Virtual Machine (JVM) examine only one section of code or individual bytecode at a time rather than examining the program as a whole and do not retain any code translations following a code section's execution. Consequently, optimizations available with many traditional compilers cannot be implemented with interpreters such as the JVM and frequently-executed code must be re-interpreted each time it is received. Additionally, interpretation detracts from overall processor performance since interpreter execution occupies processor cycles that could otherwise be utilized to execute pre-compiled code. As a result, more recent interpreted-language programming systems have begun to use dynamic compilation such as the JAVA “Just-In-Time” (JIT) compiler in addition to or in place of interpretation to improve program efficiency.
A JAVA JIT compiler, typically integrated with a JVM, dynamically compiles JAVA bytecodes into native machine code during program execution. Compilation occurs “just-in-time” on a dynamic, method-by-method basis just prior to each program method's first invocation to generate native code which is retained until the program's execution terminates. As a result, subsequent method invocations may use previously-compiled code to execute more quickly than would be possible using a bytecode interpreter alone and by the end of program execution, the program image includes native code for each method invoked during program execution. While the use of dynamic compilation such as the JAVA JIT compiler has many obvious advantages, there are negative aspects of such implementations. If compiled native code is too large to fit into a data processing system's main memory there is additional overhead associated with using virtual memory, i.e. loading and storing native code and data to and from slower storage (usually disk memory). This overhead can in turn significantly increase the execution time of dynamically compiled programs and lessen gains otherwise achieved by dynamic compilation.